REMARKS 



The enclosed is responsive to the Examiner's Office Action mailed on April 4, 
2008. A Request for Continued Examination accompanies this Amendment. At the 
time of the Office Action, claims 1 -1 7 were pending. By way of the present response, 
applicants have: 1) amended claims 1, 5, 9, and 13; 2) added no claims; and 3) 
canceled no claims. As such, claims 1-17 are now pending. Reconsideration of this 
application as amended is respectfully requested. 



Claim Rejections - 35 U.S.C. § 102 
The Examiner rejected claims 1-17 under 35 U.S.C. § 102(a) as being 
anticipated by the admitted prior art in the background of the application (hereinafter 
"Background'). 

Applicants respectfully submit that the Background does not disclose all of the 

limitations of amended claim 1 , which reads: 

A machine-implemented method for upgrading the schema of a 
database, comprising: 

updating a database update message from a first version to an 
upgraded version by chaining through one or more intermediate 
upgraded versions , wherein updating comprises 

receiving an update message having a first version 
format, and 

repeatedly generating a revised update message 
having a next most recent version format based on the 
update message until a final update message having the 
upgraded version format is generated; and 
applying the revised update message to the database to write 
an upgraded version of the schema of the database. 

(Amended claim 1 , emphasis added). 
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Applicants do not dispute the Office Action's assertion that the Background 
discloses that "[d]atabase software will generally support upgrading from any of several 
previous versions." (Background of the present application, page 1 , lines 18-20). 
However, applicants are not claiming a method and apparatus for simply upgrading a 
database from any of several previous versions. Applicants claim upgrading a database 
by release chaining . The Background does not disclose updating "by chaining through 
intermediate versions," nor does it disclose "repeatedly generating a revised update 
message having a next most recent version format based on the update message until 
a final update message having an upgraded version format is generated." In contrast, 
the Background states that: 

In existing systems, each new software release provides separate 
modules for each prior release from which an upgrade is possible. 
Upgrade code must be developed to map each of these three old releases 
into the current release, with all of the upgrade code for each new 
version written anew in each release (using older release code as a 
model). Thus, if the latest database software is at release 4, and 
assuming that releases have been numbered only at full numeral versions 
(e.g., release 1 , release 2, and release 3), then the upgrade code for 
release 4 must contain code to convert the databases to release 4 
directly from release 1 , release 2, or release 3. 

The current upgrade system requires the duplication of code for 
mapping and writing databases for each prior supported version. This 
also increases complexity in code as analysis must be done between any 
prior release and the newest release to understand how different versions 
must be changed to arrive at the latest release. For example, developing 
the release 2 to release 4 upgrade code using the current approach 
involves understanding the changes from release 2 to release 3, and 
release 3 to release 4, and combining them into a single module . In 
addition, the complexity of mapping an update message into the database 
itself must also be included in each set of upgrade code. 

(Background of present application, page 2, line 14 - page 3, line 14). 

The Background discloses a method of updating directly from the existing version 

to the upgraded version without chaining through intermediate versions and repeatedly 
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generating a revised update message having a next most recent version format based 
on the update message until a final update message having an upgraded version format 
is generated. 

If the Office Action is asserting that the Background discloses upgrading directly 
from one version to the next (e.g., from release 1 to release 2) and then one could 
repeat that process (e.g., from release 2 to release 3), the Background still fails to 
disclose the limitations of claim 1 . Claim 1 discloses repeatedly generating a revised 
update message by chaining update messages and then applying the revised update 
message to the database, not applying each update message separately to the 
database. 

Given that claims 2-4 are dependent claims with respect to claim 1 , either directly 
or indirectly, and add additional limitations, applicants submit that claims 2-4 are not 
anticipated by the Background under 35 U.S.C. § 102(a). 

Given that claims 5-8, 9-12, and 13-17 were rejected based upon the same art 
and rationale as claims 1-4 and claims 5-8, 9-12, and 13-17 have similar limitations as 
claims 1 -4 that are not disclosed in the Background, applicants submit that claims 5-8, 
9-1 2, and 1 3-17 are not anticipated by the Background under 35 U.S.C. § 1 02(a) for the 
same reasons as discussed above. 

Applicants, accordingly, respectfully submit that the rejection of claims 1-17 
under 35 U.S.C. § 102(a) as being anticipated by the Background has been overcome. 

The Examiner also rejected claims 1 -1 7 under 35 U.S.C. § 1 02(a) as being 
anticipated by Hug, et al., U.S. Patent No. 5,806,078 (hereinafter "Hug"). 
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In reference to claim 1 , the Examiner stated that: 

Hug discloses "a method for upgrading a database" [see col. 79, 
lines 5-23], comprising: 

"updating a message from a first version to an upgraded version by 
chaining through intermediate versions" [i.e., version data file 40 and the 
difference data file 42 to reflect the changes in the subsequent version; 
col. 5 lines 38-41], 

"wherein updating comprises: receiving an update message having 
a first version format" [i.e., regenerating version (20); see col. 5, lines 38- 
46]; "and repeatedly [i.e., iteratively repeat; see col. 5, lines 58-60] 
generating a revised update message having a next most recent version 
format based on the update message until a final update message having 
an upgraded version format is generated" [see col. 5, lines 48-56]. 

(Office action dated April 4, 2008 page 6). 

It is respectfully submitted that Hug does not disclose all of the limitations of 
amended claim 1 . Hug discloses a "version management system for storing and 
retrieving changes to spreadsheet and word processor documents" which permits "a 
user to access a plurality of versions" of those documents. (Hug, Abstract). "An original 
version of each document and all alternative versions are stored in a delta format, i.e., 
storing only the differences from a prior document version, in a common difference data 
file and version data file." (Hug, Abstract). "The difference data file 42 contains sets of 
data records reflecting the delta-formatted differences from each prior version of a 
document, e.g., the changed data and the cell location in a spreadsheet." (Hug, col. 6, 
lines 7-1 1 ). "[T]he version data file 40 contains a set of pointers 54 for each stored 
document version that point to a set of data records in the difference file 42 that are 
used to regenerate each document version." (Hug, col. 6, lines 22-27). 

Hug does not disclose a "upgrading the schema of a database." In contrast, Hug 
compares the differences between data edits made by a user to a document and stores 
those differences in a set of files. The Examiner made reference to Hug, col. 79, lines 
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5-23 (Office action dated September 21 , 2007 page 4). Applicants respectfully direct 
the Office's attention to the fact that Hug does not contain a column 79 . Applicants 
assume that the Office Action was referring to Nakagawa, a reference of a previous 
rejection, as rejections are often modeled after previous rejections (see Office action 
dated September 21 , 2007 page 2). The basis for the Examiner's rejection was 35 
U.S.C. § 1 02(a), not 35 U.S.C. § 1 03. There was no discussion of a combination of the 
two patents and no articulation of a motivation to combine the two patents. 

Nonetheless, even if the Examiner had based the rejection upon 35 U.S.C. §103, 
applicants respectfully assert that one of ordinary skill in the art would not be motivated 
to combine the references and, even if combined, the combination would still lack the 
limitations of amended claim 1 . Nakagawa discloses a client program to detect 
software updates, download them from a server, and update the software "according to 
the update instruction information when it is received." (Nakagawa, Abstract). 
Nakagawa does not disclose a "upgrading the schema of a database." 

Furthermore, Hug does not disclose "updating a message from a first version to 
an upgraded version by chaining through intermediate versions ... receiving an update 
message having a first version format; and repeatedly generating a revised update 
message." In contrast, the contents of the version control files in Hug are the data 
edited by a user and pointers to the locations in the document of the data edited by a 
user. Hug applies each individual delta version of the data to the original in succession 
until reaching the desired version. Hug does not disclose generating a revised update 
message by release chaining and then applying the revised update message to a 
database. 
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Given that claims 2-4 are dependent claims with respect to claim 1 , either directly 
or indirectly, and add additional limitations, applicants submit that claims 2-4 are not 
anticipated by the Hug under 35 U.S.C. § 102(a). 

Given that claims 5-8, 9-12, and 13-17 were rejected based upon the same art 
and rationale as claims 1-4 and claims 5-8, 9-12, and 13-17 have similar limitations as 
claims 1 -4 that are not disclosed in the Hug, applicants submit that claims 5-8, 9-12, 
and 1 3-17 are not anticipated by the Hug under 35 U.S.C. § 1 02(a) for the same 
reasons as discussed above. 

Applicants, accordingly, respectfully submit that the rejection of claims 1-17 
under 35 U.S.C. § 102(a) as being anticipated by the Hug has been overcome. 
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CONCLUSION 

Applicants respectfully submit that in view of the amendments and arguments set 
forth herein, the applicable rejections have been overcome. Applicants reserve all 
rights under the doctrine of equivalence. 

Pursuant to 37 C.F.R. 1 .1 36(a)(3), applicants hereby request and authorize the 
U.S. Patent and Trademark Office to (1 ) treat any concurrent or future reply that 
requires a petition for extension of time as incorporating a petition for extension of time 
for the appropriate length of time and (2) charge all required fees, including extension of 
time fees and fees under 37 C.F.R. 1 .1 6 and 1 .1 7, to Deposit Account No. 02-2666. 

Respectfully submitted, 

Blakely, Sokoloff, Taylor & Zafman LLP 

Date: July 7, 2008 /Ryan W. Elliott/ 

Ryan W. Elliott 
Reg. No. 60,156 

1 279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(408) 720-8300 



Inventor(s): Jerome A. Mouton, Jr. et al. 
Application No.: 09/295,690 



- 13 - 



Examiner: Jean B. Fleurantin 
Art Unit: 21 62 



